Remarks 

In the Final Office Action mailed September 9, 2005: 

1. Claims 1-26 were rejected under 35 U.S.C. § 103(a) as being unpatentable over 

Admitted Art (AA) and U.S. Patent No. 5,812,767 (Desai), in further view of U.S. 
Patent Application Publication 2003/01 10285 (Banerjee). 

I Desai (U.S. Patent No. 5,812.767) 

Desai is directed to a system for address resolution to enable a data link provider 
interface to resolve address conflicts (title). 

Desai describes the operation of a network-connected DLPI (Data Link Provider 
Interface) with a driver capable of interfacing with a number of different protocols (column 1 , 
lines 25-28). When the DLPI receives data from another network station, it determines which 
protocol is being used, formats the data accordingly and forwards the data to a protocol module 
(column 1, lines 39-49). Similarly, when data are to be transmitted to another station, the DLPI 
recognizes the protocol being used and may format the data using an appropriate address 
resolution routine (column 1, lines 50-59). Thus, Desai focuses on how the DLPI receives or 
transmits data from/to a network. 

Desai does not teach or suggest all relevant aspects of Applicant's invention. 

A. Desai Does Not Receive from a Data Link User a Request to Identify a 
Communication Protocol Supported by a Data Link Provider 

In Applicant's present application, a data link user that uses the services of a DLPI is 
adapted to process communications received through a DLPI. In order to process (e.g., parse) a 
communication, the data link user (e.g., a snoop utility) needs to know the format of a 
communication protocol according to which the communication is formatted. Therefore, it may 
query the DLPI to identify the applicable protocol and/or the protocol format if it does not 
already know the format. 

In contrast, the DLPI in Desai is not queried as to what communication protocol(s) it does 
or will use, and certainly does not receive such a query from a data link user. The DLPI merely 
processes communications according to their protocols; Desai says nothing about identifying 
those protocols to a data link user. 

The Examiner cited column 1, lines 39-49 of Desai as teaching this aspect of Applicant's 
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invention. The cited portion states that, among other steps, the DLPI " recognizefs] the protocol 
being used" (emphasis added). Recognizing a protocol does not mean the DLPI is asked to 
identify the protocol . If anything, it means the opposite - that the DLPI is told what 
communication protocol is being used. 

Further, the Examiner cites the following reason for combining Desai with AA: "doing so 
would resolve protocol conflict between a data link user and a data link provider." Even if true, 
this is irrelevant . 

In claimed embodiments of the invention, a DLPI is asked (not told) which protocol was 
used to format a communication. In return, the DLPI identifies the format of the communication 
protocol to a data link user or otherwise enables the data link user to parse the communication. 
There is no "protocol conflict" between the data link provider and data link user in this 
circumstance, as the data link user does not even know the protocol. 

In addition, Desai only appears concerned with network-side operations - receiving data 
from or sending data to a network (column 1, lines 25-28; column 1, lines 60-63). Because 
Desai is not concerned with the operation of data link users, it would not be considered by 
anyone attempting to enable a data link user to parse a communication received from a data link 
provider. 

The Examiner stated (office action, paragraph 5) that "recognizing is synonymous with 
identifying in the sense that Desai identifies the protocol and thus recognizes which protocol is 
being used." Even if true, Desai does not teach or suggest identifying the protocol to a data link 
user as recited in claims of the application. One result of Applicant's claimed embodiment of the 
invention is that a data link user is enabled to parse a communication formatted according to a 
protocol it did not know. Desai does not teach or suggest this. 

II Baneriee (U.S. Patent Application Publication No. 2003/01 10285) 

Banerjee is directed to the generation of an XML document to represent an exchange of 
network protocol packets (Abstract; Summary), and does not teach or suggest all relevant aspects 
of Applicant's invention. 

A. Banerjee Does Not Enable a Data Link User to Parse a Communication 
Formatted According to a Particular Protocol 

In embodiments of Applicant's invention, in response to its request for the identity of a 
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communication protocol, a data link user is enabled to parse a communication formatted 
according to the protocol. The portions of Banerjee cited in the rejection of claim 1 describe 
Banerjee's goal of generating an XML document to represent network protocol packet exchanges 
(page 3 [0043]), and the use of such a document to investigate network communication problems 
(page 5 [0071]), not the format of a network protocoL 

The Examiner stated that "Banerjee does teach enabling a data link user to parse a 
communication packet." Applicant disagrees. 

Independent claims of the present application have been amended to make it clearer that 
the data link user is enabled to parse a communication formatted according to a particular 
protocol. 

First, it is assumed that the Examiner is equating Banerjee's XML parser with 
Applicant's data link user. In particular, in the 3*^^ paragraph of page 5 of the office action, the 
Examiner states that "Banerjee does teach sending a data link user an XML (Extensible Markup 
language) document describing conmiunication protocol format". 

However, Banerjee's XML parser apparently merely "document[s] ... TCP/IP connection 
setup" (page 5, paragraph [0073]), determines "whether the TCP/IP connection sequence was 
proper" (page 5, paragraph [0078]), "represent[s] a generic TCP/IP close connection sequence" 
(page 6, paragraph [0082]), determines "whether the close setup connection was successful" 
(page 6, paragraph [0084]), etc. 

To do so, the parser does not parse a protocol : it merely looks for a particular sequence of 
events in an XML document or the exchange of certain packets. As Banerjee specifies, the XML 
document "represents network protocol packet exchanges'' (e.g., page 1 [0010]; emphasis 
added), not actual packets . The parser therefore parses descriptions of communication events, 
not packets, and therefore cannot teach another entity to parse the packets . See Figures 11, 15, 
17 of Banerjee. 

More importantly, even if an XML parser in Banerjee can parse a packet, it is not enabled 
to do so by the entity that generated the XML document (e.g., a data link provider), and was not 
enabled to do so in response to a request to identify a communication protocol. 

Second, if it is the entity that generates the XML document in Banerjee that is being 
equated with Applicant's data link user, that entity must already know how to parse the 
communication protocol. There is no suggestion that the entity is taught how to parse the 
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protocol to generate the document. In particular, Banerjee specifies that "Knowing the 
connection establishment, the transition state of each user data packet and the close connection 
procedures of TCP ... a software program may be written to convert TCP data transactions into 
an XML document" (page 5 [0071]; emphasis added), indicating that the "ability" to parse the 
protocol is hard-wired. 

Thus, Banerjee may describe generating an XML document from TCP data transactions, 
but there is no description of teaching or enabling anything (i.e., a data link user) to parse a 
communication protocol, especially not in response to a request to identify a communication 
protocol . 

Further, because Banerjee is hard-wired to work with one specific protocol (i.e., TCP), 
there is no need to leam how to or to be enabled to parse another protocol, and one skilled in the 
art looking for a way to enable a data link user to parse a communication formatted according to 
an unknown protocol would not look to Banerjee . Banerjee thus teaches away from Applicant's 
invention. 

Ill Selected Claims 

A. Claims 1-6 

Claims 1 and 6 have been amended to make it clearer that the data link user receives from 
a data link provider information enabling the data link user to parse a communication formatted 
according to a particular protocol. 

As described above, in Desai a DLPI may recognize a protocol but it does not suggest 
identifying the protocol format to a data link user. And, Banerjee discusses portraying an 
exchange of packets, not teaching a data link user the format of a communication protocol. 

B. Claims 7-12 

Claims 7 and 12 have been amended to make it clearer that the data link user receives 
from a data link provider information enabling the data link user to parse a communication 
formatted according to a particular protocol. 

As described above, in Desai a DLPI may recognize a protocol but it does not suggest 
identifying the protocol format to a data link user. And, Banerjee discusses portraying an 
exchange of packets, not teaching a data link user the format of a communication protocol. 
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C. Claims 13-19 

Claims 13 and 19 have been amended to make it clearer that a data link user is enabled to 
parse a communication formatted according to a protocol it did not know. As described above, 
in Desai a DLPI may recognize a protocol but it does not suggest identifying the protocol format 
to a data link user. And, Banerjee discusses portraying an exchange of packets, not teaching a 
data link user the format of a communication protocol. 

D. Claims 20-26 

Claim 20 has been amended to make it clearer that the data link user receives from a data 
link provider information enabling the data link user to parse a communication formatted 
according to a protocol previously unknown to the data link user. 

As described above, in Desai a DLPI may recognize a protocol but it does not suggest 
identifying the protocol format to a data link user. And, Banerjee discusses portraying an 
exchange of packets, not teaching a data link user the format of a communication protocol. 

Claim 26 specifies that the data link provider enables the data link user to access, on the 
data link provider, processor executable instructions for parsing the protocol. Banerjee does not 
do this. As described above in Section II.A, Banerjee sends an XML parser an XML document 
describing exchanges of packets. Even if the XML parser could be considered "processor 
executable instructions," in Banerjee those "instructions" are sent to the XML parser . They are 
not accessed on a data link provider. 



CONCLUSION 

No new matter has been added with the preceding amendments. It is submitted that the 
application is in suitable condition for allowance. Such action is respectfully requested. If 
prosecution of this application may be facilitated through a telephone interview, the Examiner is 
invited to contact Applicant's attorney identified below. 
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Respectfully submitted, 




Date: October 1 1 . 2005 By: pCiZ^y / l/wgL^ 42.199 

Daniel E. Vaughan 0 (Registration No.) 

Park, Vaughan & Fleming LLP 

39180 Liberty Street, Suite 103 
Fremont, CA 94538 
(510) 790-9960: voice 
(510) 790-9964: facsimile 
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